IBIS Macromodel Task Group Meeting date: 9 February 2021 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Luminous Computing * David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that given the groups' decision and Fangyi's new BIRD draft, he had moved all the other redriver flow proposal agenda items to the Tabled topics. - Arpad noted that Hansel had a new "Clarification of PAM4 Thresholds" document for us to review. He said we could plan to review it today time permitting. ------------- Review of ARs: - Fangyi to send out the Redriver BIRD draft and updated slides. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 2nd meeting. Curtis moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Redriver Flow Issues: Fangyi shared his updated presentation "AMI Redriver flow". He noted that he had added clarifying text regarding the value the EDA tool could pass in with the Use_New_Flow parameter: The EDA tool can set the value to either True or False in the AMI_Init function call regardless of the value specified in the .ami file. Arpad brought up a point he had raised in an email reply to ATM prior to the meeting. Arpad said he thought the Use_New_Flow parameter should be Format List, not Value. He said he thought if we expect user interaction to set the parameter's value then it should be a List of choices (True, False in this case, as the Type is Boolean). If it is of Format Value, then he thought its value was being strictly defined by the .ami file, and the GUI of the EDA tool shouldn't allow the user to modify it. Fangyi said there's no difference between the tool deciding to modify it or letting the user decide. As far as the specification is concerned, it's only that the intention is that the caller of AMI_Init can decide what value is to be passed to the model. Fangyi noted that some Usage In Reserved Parameters of Format Value, such as DLL_ID, specify placeholder values in the .ami file that are replaced by the EDA tool. Curtis said he understood the approach in Fangyi's draft, because it does seem a bit counterintuitive that you can't just specify Type Boolean and Format Value and assume the value can be set to True or False for the In parameter. In fact, since this is a Reserved Parameter, we probably could define the behavior as Fangyi had. However, the definition of Format Value in the specification states that the model maker is providing the value to be used. So, in a case like this where it's an In parameter and we want the tool/user to decide amongst 2 choices, he thought Arpad's suggestion of Format List was correct. Fangyi said he had gotten similar feedback regarding using Format List from Walter. Fangyi asked if it would satisfy everyone if he changed it to Format List and stated that the List must include both True and False. No one objected. Ambrish said the user/tool would be making this decision based upon all of the models in the channel since the new flow requires all models to support it. Walter said that isn't necessarily a requirement in practice. For example, you could have a legacy Rx and a new flow Tx, and this could be a perfectly legitimate flow. Fangyi asked if the legacy Rx would know what to do with the additional information in the IR matrix. Walter said the EDA tool could/would know not to provide the two extra columns to the legacy Rx. Fangyi noted a section he had added to the statistical flow descriptions based on Walter's input: Note that the input and output impulse_matrix of each AMI_Init call in this alternative Redriver channel statistical flow are identical respectively to those of the corresponding AMI_Init call in the alternative Redriver channel time domain flow. Arpad suggested that Fangyi also add sub-headings to highlight the start of each of the 4 new flow descriptions to make the proposal easier to read. Arpad suggested that "can" be changed to "may" in all instances of "... can use filter impulse response". Fangyi agreed with both suggestions. Ambrish asked if the name Use_New_Flow had been discussed and whether it would age well. Arpad said there was agreement that a better name is needed. Arpad said he had suggested something indicating the version of the specification in which it was introduced (e.g., 7p1 as part of the name representing IBIS 7.1). He said we used to refer to the "5.1 flows" as opposed to the original 5.0 AMI flows. Bob didn't like this idea, and he noted that we already have a table in the specification that documents the version in which each of the Reserved Parameters was introduced. He said the parser would already reject the new parameter if someone attempted to use it in a .ami file with an earlier version. Fangyi suggested Arpad and Ambrish take an AR to come up with a better name. Ambrish asked if the proposal is only addressing statistical flow, and he asked if we agree that the current flow works if all models have GetWave. Fangyi agreed that the current time domain flow works if all models have GetWave. However, he said this proposal is not just addressing statistical flows. He shared the Definition of the Issue: section of the BIRD, and he noted that issue #3 is the problem with deconvolution being required when the Tx has a GetWave and the Rx is Init-Only. The new flow will address that problem too, and it's not limited to redriver flows. Walter agreed. Fangyi reluctantly asked whether we should update the regular flow descriptions too. Arpad said that if this new flow proposal fixes those too, then we should update them. Fangyi said maybe that should be another BIRD. Arpad thought we should probably fix them all at once, since EDA vendors will be updating their flows based on this BIRD. Ambrish asked how often anyone has seen a case where the Tx model has GetWave and the Rx model is Init-Only. Arpad said Tx models and Rx models could come from different vendors, so this combination could occur. Ambrish agreed, but he asked how often in our ten years of AMI experience this happened? Walter said the Tx model author will want his model to work in any flow, and this new flow is a best-practice: Init and Get-Wave should be provided, and Init should return its equalization. Arpad asked if we should have a straw poll next week to decide on whether to address the regular flows as well. Ambrish asked if we should wait until there's a real problem before we fix it. Fangyi suggested everyone think about it until next week. Fangyi took an AR to send out his BIRD draft with the suggested updates from the meeting. Arpad asked him to mention in his email the question about whether to also update the regular flows. AR: Fangyi to email his updated redriver flow BIRD draft and mention the question about whether to update the regular flows as well. AR: Arpad and Ambrish to suggest a better name for Use_New_Flow. ------------- Next meeting: 16 February 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives